Thanks for the PR! Can you revert the formatting changes?

Ah nevermind, I see that there's an extra loop now.

Currently in the process of testing an alternative implementation for this btw, so no need to bother fixing phpstan for now.

Could you provide some concrete reproduction steps for the bug first? ALTER ROLE (central user) NOBYPASSRLS in our tests doesn't seem to do it.

The user that is used as the central user in tenancy should not have the superuser or bypassrls.

Could you try with:

ALTER USER *central user* NOBYPASSRLS

Or just create a new user:

create user *central user*
    createdb
    createrole;

Some possible steps to follow:

1. create central_user (see above)
2. setup database grants grant connect, create, temporary on database *yourdatabase* to *central user*;
3. setup schema grants grant create, usage on schema *yourschema* to *central user*;
4. setup tenancy with that user
5. run 'artisan tenants:rls'
6. check if central user can see all resources

Without this pull request the app will throw a error or just not select the data, because the user cannot access the data without rls bypass.

You can check the policies by running select * from pg_policies.

Thanks, we managed to reproduce the issue with those steps. I have a few questions though:

1. What would be a case where the central user has enough permissions to create users and create RLS policies, but not bypass them? If you can grant the former two, I imagine you could just use BYPASSRLS? The only case where I see this not being possible is if you're using RLS yourself for other things and explicitly don't want to use BYPASSRLS.
2. Instead of making two separate policies, we could just remove FORCE ROW LEVEL SECURITY which should still enforce RLS for the tenant user, but not the central user as it's the table owner.